Distributed processing networks are being increasingly used for live voice communications between network nodes using Voice over IP or VoIP technology. In VOIP technology, after the speech is digitized, the digitized speech is divided into packets. Each packet includes a header and a data payload of one to several frames of encoded speech. Distributed processing networks for delivering the packets to desired endpoints are typically designed to provide a Best Effort or BE single service model that does not discriminate in packet delivery between services and does not control service access or quality. Quality of Service or QoS architectures have been developed for BE environments to provide guaranteed transmission characteristics end-to-end such as available bandwidth, maximum end-to-end delay, maximum end-to-end delay variation (jitter), and packet/cell loss levels to provide continuous data streams suitable for real-time phone calls and video conferencing. Such QoS architectures include protocols such as the Resource ReSerVation Protocol or RSVP and the Real-Time Transfer Protocol or RTP.
RSVP is a signaling protocol that guarantees receivers a requested end-to-end QoS. RSVP serves as an Internet signaling protocol through the transmission of QoS parameters. Under RSVP, an end point negotiates with the network to allocate or reserve protected resources for traffic that the end point will generate or receive. The two messages that perform the reservation request and installation are the Path and Resv messages. Robustness is achieved through maintaining a soft state network by transmitting periodic refresh messages to maintain a reservation and path state along the reservation path. If the intermediate nodes do not receive the refresh message, the reservation will time out and be deleted.
RTP is a voice bearer channel transfer protocol. RTP neither guarantees a QoS nor provides for resource reservations. RTP runs on the transport layer of the Open Systems Interconnection or OSI model and defines a session by two components, namely its profile and payload format where the payload is the data being transmitted. The payload format specifies the format of the data within the RTP packet such as encoding and compression schemes. RTP functions include loss detection for quality estimation and rate adaptation, sequencing of data, intra- and intermedia synchronization, session identification using a session id, source identification using a synchronization source id or SSRC, and basic membership information.
The Real-Time Control Protocol or RTCP, a companion protocol to RTP, is used by applications to monitor the delivery of RTP streams. Media packets are transmitted between endpoints during a session according to RTP while additional performance information governing the communication link (e.g., key statistics about the media packets being sent and received by each end point such as jitter, packet loss, round-trip time, etc.) are collected by the end points and transmitted to a session monitor according to RTCP. The network monitor can be, for example, VoIP Monitoring Manager™ or VMon™ by Avaya, Inc.
Under either the RSVP or RTP protocols, VoIP introduces a whole new range of QoS problems which were not previously significant or, in some cases, even encountered in circuit-switched networks. Voice telephony depends upon reliable, low latency, real-time delivery of audio data. In VoIP, values for latency, packet loss, and jitter can increase substantially, particularly during periods of heavy network traffic, causing a user to experience a much poorer quality of communication (e.g., audio or video distortion, unacceptable levels of asynchronization between audio and video streams, etc.) than would be experienced if the call were made by a traditional circuit-switched telephony network. This is particularly true when the network allows any and all calls to occur, regardless of available bandwidth and the concomitant low quality of the call to be placed and the detrimental impact on the quality of other calls.
To provide a higher QoS, call admission control (CAC) functionality has been employed to control bandwidth usage. In one approach, CAC-type functionality is built into the communication protocol. For example, in RSVP calls are disallowed when a reservation fails. In another approach, CAC functionality is built into the switch or media server (e.g., the Private Branch Exchange or PBX). Under the H.323 standard for example, an endpoint in the H.323 zone of a call admission controller or gatekeeper must receive permission (using a bandwidth request message) from the call admission controller before making a call. Based on a restriction on the number of concurrent IP calls that can be placed generally and/or on a critical measure, such as not being able to reserve the bandwidth required, the call admission controller responds with a bandwidth confirm message permitting the call to be placed or a bandwidth reject message refusing to make the necessary connection for the call. The remaining bandwidth is reserved for electronic mail, file transfers, and other local-area network or LAN protocols.
Although a higher QoS can be realized using CAC functionality, there are drawbacks. First, there is no reason provided to the user regarding the failure to place the call. This can lead to user frustration and ultimately to a lack of utilization of IP telephony. Although some telephones, such as the Cisco IP Phone 7960™, do permit a user to press a button and view the current values for latency, packet loss, and jitter, this feature is only enabled after a call is placed. Second, it can be very difficult for a call admission controller to determine accurately whether or not to place a call. For example, if the controller is in a first subnet, a first endpoint is in a second subnet, and a second endpoint is in a third subnet, the controller is often unable to determine whether or not there is sufficient bandwidth available between the second and third subnets for the first and second endpoints to conduct a communication of acceptable quality. Although the controller can base the decision on pings to the second and third subnets, this is generally not an accurate indicator of available bandwidth. Third, CAC techniques provide the user with no option about placing the call if predefined criteria are not satisfied. There are situations when a user may want to place a call even though the call may be of poor quality. For example, a user may want to place a call in an emergency situation.